Programmable devices, such as SRAM-based FPGAs, can be rapidly reconfigured to perform many different functions. Typically, programmable devices include a number of different functional units connected by programmable interconnections. The functions of programmable device are determined by configuration data, which defines the configuration of the functional units and the programmable interconnections between them. This, in turn, defines the overall functions of the programmable device.
One common type of defect in all semiconductor devices is a bridging fault. A programmable device typically implements programmable interconnections as one or more layers of a large number of closely-spaced conductive lines, typically made of metal or other electrically conductive materials. Due to variability in the manufacturing process, adjacent conductive lines can be unintentionally short-circuited together. This type of defect is referred to as a bridging fault. Bridging faults can arise from numerous sources, such as an excess of conductive material remaining between the conductive lines, or defects in the multiplexers or other control circuitry used to selectively connect the conductive lines to functional units, power supplies, and inputs and outputs of the programmable device.
Detecting bridging faults requires driving adjacent conductive lines to opposite electrical states, for example ground and Vcc, and observing the outputs of the conductive lines. If a pair of adjacent conductive lines can be driven to opposite states, there are no bridging faults between the pair of adjacent conductive lines. Because of their large number of programmable interconnects, typical programmable devices can have tens of thousands of conductive lines or more. In contrast to the large number of programmable interconnects, programmable devices typically have a relatively limited number of inputs and outputs. As testing each pair of adjacent conductive lines requires a minimum connection with two unique control points, which drive each line to opposite states, and one observation point, testing an entire programmable device requires reconfiguration with thousands of different sets of test configuration data to connect all of the conductive lines. This increases the time, and consequently the cost, of testing for programmable devices.
FIGS. 1A and 1B illustrate prior systems that improve the performance of testing for bridging faults. FIG. 1A illustrate programmable device 100 having an implicit control system and including adjacent conductive lines 105 and 110. Due to a manufacturing defect, a bridging fault 115 exists between lines 105 and 110. To detect bridging fault 115, line 105 is connected to control input 125, which is used to drive line 105, and output 130, which is used to observe the state of line 105. Line 110 is not connected to any control input. Instead, programmable device 100 includes a half latch that automatically drives all unconnected lines, such as line 110, to a default electrical state, for example Vcc. As unconnected lines can be implicitly driven to a default electrical state without a control input, there are more control inputs available for testing, decreasing the number of test configurations needed.
However, full bridging fault test coverage cannot be achieved with the implicit control method. If the half latch driving unconnected lines high is stronger than the control input driving an adjacent line low, the output of the adjacent line will be high and the bridging fault will be observed. Conversely, if the half latch driving unconnected lines high is weaker than the control input driving an adjacent line low, the output of the adjacent line will be low, as expected, and the bridging fault will be undetected. Thus, in an implicit control system, even if every line is explicitly controlled and observed once, only 50% of the possible faults can be covered.
One prior alternate way to make bridging fault test generation more tractable is to narrow down the breadth of the test by explicitly driving each conductive line coming into a multiplexer via other resources. FIG. 1B illustrates a programmable device 150 in which testing is narrowed to a set of multiplexer inputs. Adjacent conductive lines 155 and 160 are connected to a multiplexer 170 and have a bridging fault 165. To detect bridging fault 165, lines 155 and 160 are driven to opposite electrical states and the output of the multiplexer is observed as it is selectively connected to each of its inputs.
The difficulty with this type of bridging fault test arises in attempting to identify and track adjacent conductive lines. Precise layout information is huge and is hard for the software to manage it efficiently. Additionally, some defects in multiplexers manifest as bridging faults between lines that may or may not be physical neighbors. This means that every line must be treated as if it had the possibility to be bridged to any other line, thereby requiring a large number of tests.
The difficulties of detecting bridging faults are further exacerbated by the increased flexibility of more advanced programmable devices. Programmable devices typically had indivisible conductive lines that ran the entire width of the device. However, more recent programmable devices allow conductive lines to be divided into segments less than the width of the device, and selectively connected to neighboring conductive lines. This increases the flexibility and routing capability of the programmable device, which improves the utilization of programmable device resources, but increases the potential for bridging faults.
It is therefore desirable for a bridging fault detection system to allow for a high amount of test coverage using a low number of test configurations. It is further desirable that the bridging fault detection system automatically create optimal test configurations and test vectors without the need for precise layout information, and be readily adaptable to complex programmable device architectures. It is still further desirable that the bridging fault detection system allow testers to specify a precise level of testing coverage.